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Abstract 


This document describes an Extensible Provisioning Protocol (EPP) extension called "Registry 
Maintenance Notification", which is used by EPP servers to notify EPP clients and allow EPP 
clients to query EPP servers regarding maintenance events. 
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Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9167. 
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1. Introduction 


The Extensible Provisioning Protocol (EPP), as defined in [RFC5730], is a protocol whose original 
motivation is to provide a standard Internet domain name registration protocol for use between 
registries and registrars. 


Registries routinely update systems to ensure a higher quality of service, implement new services, 
or upgrade protocols to the latest standards. These updates are pushed to various registry 
environments during time frames communicated to registrars as "maintenance events". 
Maintenance events may require making services unavailable for some limited time while the 
upgrade happens. Registries usually inform registrars about maintenance events in various 
formats, none of which are standardized between registries. 


The DNS namespace expansion has led to many additional registries that registrars must interact 
with, adding more maintenance events and formats. It is now desirable to provide an efficient 
approach to notify registrars. 


This document describes an extension mapping for version 1.0 of the EPP to provide a 
mechanism by which EPP servers may notify EPP clients of and allow EPP clients to query EPP 
servers on upcoming maintenance events. 


1.1. Terminology and Definitions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


XML [W3C.REC-xm1-20081126] is case sensitive. Unless stated otherwise, XML specifications and 
examples provided in this document MUST be interpreted in the character case presented in order 
to develop a conforming implementation. 


The XML namespace prefix "maint" is used for the namespace 

"urn :ietf:params:xml:ns:epp:maintenance-1.0", but implementations MUST NOT depend on it and 
instead employ a proper namespace-aware XML parser and serializer to interpret and output the 
XML documents. 


"ote" is an abbreviation for "Operational Test and Evaluation". 


In examples, "C:" represents lines sent by a protocol client, and "S:" represents lines returned by a 
protocol server. Indentation and white space in examples are provided only to illustrate element 
relationships and are not a required feature of this protocol. 


Sattler, et al. Standards Track Page3 


RFC 9167 EPP Registry Maintenance December 2021 


2. Migrating to Newer Versions of This Extension 


Servers that implement this extension SHOULD provide a way for clients to progressively update 
their implementations when a new version of the extension is deployed. A newer version of the 
extension is expected to use an XML namespace with a higher version number than the prior 
versions. 


Servers SHOULD (for a temporary migration period up to server policy) provide support for older 
versions of the extension in parallel to the newest version and allow clients to execute their 
preferred version of the <info> command based on the maintenance <objURI> elements of the 
server <greeting>. The version of the maintenance <info> response MUST match the version of the 
maintenance <info> command executed by the server. 


Servers MUST return a Registry Maintenance Notification poll message matching the newest 
negotiated version of the maintenance extension, based on an intersection of the maintenance 
<objURI> elements in the server «greeting» and the client «login» command. If the intersection of 
the maintenance <objURI> elements of the server <greeting> and the client <login> command 
results in an empty set, the server MUST return the newest version of the Registry Maintenance 
Notification poll message supported by the server based on "Usage with Poll-Message EPP 
Responses" in Section 6 of [RFC9038]. 


3. Object Attributes 


3.1. Internationalized Domain Names 


Names of affected hosts MUST be provided in A-label form, according to [RFC5891]. 


3.2. Dates and Times 


All date and time attribute values MUST be expressed in Universal Coordinated Time (UTC) using 
the Gregorian calendar. The date-time format defined as "date-time" in [RFC3339], with time- 
offset="Z", MUST be used. 


3.3. Maintenance Elements 


The <maint:item> element describes a single registry maintenance event during a specific period. 
This element is used in a maintenance item EPP <info> command and response as well as in a 
<poll> response. 


If an element is not marked as optional, it is mandatory. 
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<maint:id> 
The server-unique identifier for the maintenance event with the OPTIONAL "name" attribute 
that includes a human-readable name of the event. The server-unique identifier SHALL NOT be 
changed if the event is updated or deleted. When the "name" attribute is set, the OPTIONAL 
"lang" attribute, per the language structure in [RFC5646], MAY be present to identify the 
language if the negotiated value is something other than the default value of "en" (English). 


<maint:type> 
Zero or more OPTIONAL types of the maintenance event, with the possible set of values 
defined by server policy, such as "Routine Maintenance", "Software Update", "Software 
Upgrade", or "Extended Outage". The OPTIONAL "lang" attribute MAY be present to identify the 
language if the negotiated value is something other than the default value of "en" (English). 


<maint:pollType> 
The OPTIONAL <maint:pollType> element for a Registry Maintenance Notification poll 
message; values MUST be "create", "update", "delete", "courtesy", or "end". For the "create" and 
"update" types, the server includes the state of the maintenance event after the creation or 
update. For the "delete" type, the server includes the state of the event before the delete. The 
"courtesy" provides a reminder of an event, and the "end" provides a notification of the end of 
the event without updating the maintenance object and includes the latest state of the event. 
This element MUST be present only for poll messages. 


<maint:systems> 
One or more <maint:system> elements that are affected by the maintenance event. 


<maint:system> 
The <maint:system> element contains the following child elements: 


<maint:name> 
The name of the affected system, such as "EPP", "WHOIS", "DNS", "Portal", "RDAP", etc. 


<maint:host> 
The OPTIONAL affected maintained system's hostname, which SHALL be in A-label form, 
according to [RFC5891]. 


<maint:impact> 
The impact level; the values MUST be "full", "partial", or "none". If access is expected to be 
intermittently unavailable, it is "partial". If access is expected to be completely 
unavailable, it is "full". If access is not affected, it is "none". 


<maint:environment> 
The type of the affected system; the attribute "type" is REQUIRED and MUST be "production", 
"ote", "staging", "dev", or "custom". For extensibility, the <maint:environment> element 
includes the OPTIONAL "name" attribute that can define the name of the custom environment 
when the <maint:environment> element "type" attribute has the "custom" value. For example, 
for the custom "marketing" environment, the <maint:environment> element should be: 


«maint:environment type-"custom" name="marketing"/>. 
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<maint:start> 
The date and time of the start of the maintenance event. 


<maint:end> 
The date and time of the end of the maintenance event. The <maint:end> element MUST be 
greater than the <maint:start> element. 


<maint:reason> 
The reason behind the maintenance event; the values MUST be either "planned" or 
"emergency". 


<maint:detail> 
The OPTIONAL URI to the detailed maintenance event description, formatted according to 
[RFC3986]. 


<maint:description> 
Zero or more OPTIONAL free-form descriptions of the maintenance event, usable without 
creating and traversing an external resource as defined by the <maint:detail> element. The 
OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is 
something other than the default value of "en" (English). The OPTIONAL "type" attribute MAY be 
present to identify the format of the description. It MUST be either "plain" for plain text or 
"html" for HTML text, as defined in [HTML5], and XML-escaped, with a default value of "plain". 


<maint:tlds> 
The OPTIONAL <maint:tlds> element contains one or more <maint:tld> child elements. If the 
<maint:tlds> is not present, the entire system is affected. 


<maint:tld> 
The affected top-level domain or registry zone, which SHALL be in A-label form, according 
to [RFC5891]. 


<maint:intervention> 
The OPTIONAL <maint:intervention> element contains the following child elements: 


<maint:connection> 
The value SHALL be boolean and indicates if a client needs to perform a connection- 
related action such as a reconnect. The attribute should only be used as a flag to 
indicate connections will be affected. Servers SHOULD include a description of how the 
connections are affected in the <maint:description> element or use the <maint:detail> 
element above. 


<maint:implementation> 
The value SHALL be boolean and indicates if a client needs to perform an 
implementation-related action such as a code change. The attribute should only be used 
as a flag to indicate implementation will be affected. Servers SHOULD include a 
description of how the implementation is affected in the <maint:description> element 
or use the <maint:detail> element above. 
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<maint:crDate> 
The date and time of the maintenance object creation. 


<maint:upDate> 
The OPTIONAL date and time of the most recent maintenance object modification. This 
element MUST NOT be present if the maintenance object has never been modified. 


4. EPP Command Mapping 


A detailed description of the EPP syntax and semantics can be found in the EPP core protocol 
specification [RFC5730]. The command mappings described here are specifically used to notify 
registrars of registry maintenance events and object mapping. 


4.1. EPP Query Commands 


EPP [RFC5730] provides three commands to retrieve object information: «check» to determine if 
an object is known to the server, «info»? to retrieve detailed information associated with an 
object, and «transfer» to retrieve object transfer status information. 


This extension does not add any elements to EPP «check» and «transfer» commands or 
responses. 


4.1.1. EPP «info» Command 


EPP provides the «info» command that is used to retrieve registry maintenance information. In 
addition to the standard EPP command elements, the «info» command MUST contain a 
<maint:info> element that identifies the maintenance namespace. 


The «maint:info» element MUST contain a child element. It is either the «maint:id» child element, 
described in Section 4.1.1.1, to query for a specific maintenance item or the <maint:list> child 
element, described in Section 4.1.1.2, to query all maintenance items. 


4.1.1.1. Info Maintenance Item 


The information regarding a specific maintenance item can be retrieved by using the «info» 
command with the «maint:info» element and the <maint:id> child element, defined in Section 3.3. 
Ifthe maintenance identifier does not exist, the server MUST return an EPP error result code of 
2303 ("Object does not exist") [RFC5730]. 


The following is an example of retrieving a specific maintenance item in an «info» command. 
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C:«?xml version="1.0" encoding="UTF-8" standalone="no"?> 
C:«epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> 


C: «command» 

CE <info> 

CE <maint:info 

CE xmlns:maintz"urn:ietf:params:xml:ns:epp:maintenance-1.0"» 
Ge «maint:id»2e6df9b0-4092-4491-bcc8-9fb2166dcee6«/maint:id» 
Ge </maint :info> 

C: </info> 

Ge <c1lTRID>ABC-12345</c1TRID=> 

C: </command> 

C:</epp> 


When an <info> command has been processed successfully, the EPP <resData> element MUST 
contain a child <maint:infData> element that identifies the maintenance namespace. The 
<maint:infData> element contains the <maint:item> element defined in Section 3.3. 


The following is an example of returning a specific maintenance item in an <info> response. 
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S:<?xml version="1.0" encoding="UTF-8" ?> 
S:«epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> 
<response> 
«result code-"1000"» 
<msg>Command completed successfully</msg> 
</result> 
<resData> 
<maint:infData 
xmlns:maint-"urn:ietf:params:xml:ns:epp:maintenance-1.0"» 
<maint:item> 
«maint:id»2e6df9b0-4092-4491-bcc8-9fb2166dcee6 
«/maint:id» 
«maint:type lang="en">Routine Maintenance</maint :type> 
<maint :systems> 
<maint :system> 
<maint :name>EPP</maint :name> 
<maint:host>epp.registry.example 
</maint :host> 
<maint :impact>full</maint :impact> 
«/maint:system» 
«/maint:systems» 
«maint:environment type="production"/> 
«maint:start»2021-12-30T06:00:00Z«/maint:start» 
«maint:end»22021-12-30T07:00:00Z«/maint:end» 
«maint:reason»planned«/maint:reason» 
<maint:detail> 
https://www.registry.example/notice?123 
</maint :detail> 
<maint:description lang="en">free-text 
</maint :description> 
<maint:description lang="de">Freitext 
</maint :description> 
<maint :tlds> 
<maint :tld>example</maint :tld> 
<maint:tld>test</maint:tld> 
«/maint:tlds» 
«maint:intervention» 
<maint :connection>false</maint :connection> 
<maint:implementation>false</maint :implementation> 
</maint :intervention> 
«maint:crDate»22021-11-08T22:10:00Z«/maint:crDate» 
</maint :item> 
</maint:infData> 
</resData> 
<trID> 
<c1TRID>ABC-12345</c1TRID> 
<svTRID>54321-XYZ</svTRID> 
«/trID» 
</response> 
:</epp> 


O O 000000 0D 00D 00 00 00 00 00 00 00 0 0 00 00 00 O0 0 00 O0 00 O0 O0 00 00 O0 O0 0 0 0 0 00 00 0 O0 00 00 00 0 OO O0 O0 COD 


4.1.1.2. Info Maintenance List 


The information for a list of maintenance items can be retrieved by using the «info» command 
with the «maint:info» element and the empty «maint:list» child element. Server policy 
determines if completed maintenance events will be included in the list of maintenance items. 


Sattler, et al. Standards Track Page 9 


RFC 9167 EPP Registry Maintenance December 2021 


The following is an example of retrieving the list of maintenance items in an <info> command. 


C:«?xml version="1.0" encoding="UTF-8" standalone="no"?> 
C:«epp xmlns-"urn:ietf:params:xml:ns:epp-1.0"» 


C: «command» 

C: <info> 

Ce <maint:info 

Cc xmlns:maint="urn:ietf:params:xml:ns:epp:maintenance-1.0"> 
CE <maint:list/> 

GE </maint :info> 

CE </info> 

CE <c1TRID>ABC-12345</c1TRID=> 

C: </command> 

C:</epp> 


When an <info> command has been processed successfully, the EPP <resData> element MUST 
contain a child <maint:infData> element that identifies the maintenance namespace. The 
<maint:infData> element contains the <maint:list> element with zero or more <maint:listItem> 
child elements. The <maint:listItem> element contains the following child elements: 
<maint:id> 
The <maint:id> element defined in Section 3.3. 


<maint:start> 
The <maint:start> element defined in Section 3.3. 


<maint:end> 
The <maint:end> element defined in Section 3.3. 


<maint:crDate> 
The <maint:crDate> element defined in Section 3.3. 


<maint:upDate> 
The OPTIONAL <maint:upDate> element defined in Section 3.3. 


The following is an example of returning the list of maintenance items in an <info> response. 
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S:<?xml version="1.0" encoding="UTF-8" ?> 
S:«epp xmlns-"urn:ietf:params:xml:ns:epp-1.0"» 
«response» 
«result code="1000"> 
<msg>Command completed successfully</msg> 
</result> 
<resData> 
<maint:infData 
xmins :maint="urn:ietf:params:xml:ns:epp:maintenance-1.0"> 
<maint:list> 
<maint:listItem> 
«maint:id»2e6df9b0-4092-4491-bcc8-9fb2166dcee6 
«/maint:id» 
«maint:start»2021-12-30T06:00:00Z«/maint:start» 
«maint:end»2021-12-30T07:00:00Z«/maint:end» 
«maint:crDate»2021-11-08T22:10:00Z«/maint:crDate» 
</maint:listItem> 
<maint:listItem> 
«maint:id»91e9dabf-c4e9-4c19-a56c-78e3e89c2e2f 
«/maint:id» 
«maint:start»2021-12-15T04:30:00Z«/maint:start» 
«maint:end»2021-12-15T05:30:00Z«/maint:end» 
«maint:crDate»2021-11-08T22:11:00Z«/maint:crDate» 
«maint:upDate»2021-11-17T15:00:00Z«/maint:upDate» 
</maint:listItem> 
</maint:list> 
</maint :infData> 
</resData> 
«trID» 
«clTRID2ABC-12345«/clTRID» 
<svTRID>54321-XYZ</svTRID> 
«/trID» 
</response> 
:</epp> 


O 00000» 0000 00D 00 00 00 0 O0 00 00 00 0 0 0 O0 O0 O0 O0 0 00 O0 O0 O0 0 00 00 OO OO 


4.1.2. EPP «poll» Command 


The EPP «poll» command and response are defined in Section 2.9.2.3 of [RFC5730]. The Registry 
Maintenance Notification is included in the EPP «poll» response in [RFC5730]. 


There are five types of poll messages for the Registry Maintenance Notification, defined by the 
<maint:pollType> element in Section 3.3. A poll message might be generated when a maintenance 
event is created, updated, or deleted. A courtesy poll message can be sent as a reminder of an 
upcoming maintenance event. An end poll message can be sent when the maintenance event is 
completed. In the case of a message specific to Registry Maintenance, a «maint:infData» element 
that identifies the maintenance namespace will be included within the <resData> element of the 
standard «poll» response. The <maint:infData> element contains the <maint:item> element 
defined in Section 3.3. 


The following is an example of a «poll» command: 
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C:«?xml version="1.0" encoding="UTF-8" standalone="no"?> 
C:«epp xmlns-"urn:ietf:params:xml:ns:epp-1.0"» 

C: «command» 

(C «poll op="req"/> 

C <CITRID>ABC-12345</c1TRID> 

C: </command> 

C:</epp> 


Example <poll> response: 
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S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
S:«epp xmlns-"urn:ietf:params:xml:ns:epp-1.0"» 


0» 00 000000 D OD O0 00 0D 0 00 00 00 O0 00 00 00 00 0 0 00 00 0 0 0 00 O0 O0 O0 O0 00 00 O0 O0 0 0 O0 0 0 0 0 00 O0 O0 OO OD 


«response» 
«result code="1301"> 


<msg>Command completed successfully; ack to dequeue</msg> 


</result> 
<msgQ count="1" id="12345"> 
<qDate>2021-11-@8T22:10:00Z</qDate> 
<msg lang="en">Registry Maintenance Notification</msg> 
</msgQ> 
<resData> 
<maint:infData 


xmins :maint="urn:ietf:params:xml:ns:epp:maintenance-1.0"> 


«maint:item» 


December 2021 


«maint:id»2e6df9b0-4092-4491-bcc8-9fb2166dcee6«/maint:id» 


«maint:pollType»create«/maint:pollType» 
«maint:systems» 
«maint:system» 
<maint :name>EPP</maint :name> 
<maint:host>epp.registry.example 
</maint :host> 
<maint :impact>full</maint :impact> 
</maint:system> 
</maint :systems> 
«maint:environment type="production" /> 
«maint:start»2021-12-30T06:00:00Z«/maint:start» 
«maint:end»2021-12-30T07:00:00Z«/maint:end» 
«maint:reason»planned«/maint:reason» 
<maint:detail> 
https://www.registry.example/notice?123 
</maint :detail> 
<maint:tlds> 
«maint:tld»example«/maint:tld» 
<maint:tld>test</maint:tld> 
</maint:tlds> 
<maint :intervention> 
<maint :connection>false</maint :connection> 
<maint:implementation>false</maint :implementation> 
</maint :intervention> 
<maint :crDate>2021-11-@8T22:10:00Z</maint:crDate> 
</maint :item> 
</maint :infData> 
</resData> 
<trID> 
<c1TRID>ABC-12345</c1TRID> 
<svTRID>54321-XYZ</svTRID> 
«/trID» 
</response> 


:</epp> 
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4.2. EPP Transform Commands 


EPP provides five commands to transform objects: <create> to create an instance of an object, 
<delete> to delete an instance of an object, <renew> to extend the validity period of an object, 
<transfer> to manage object sponsorship changes, and <update> to change information 
associated with an object. 


This extension does not add any elements to the EPP <create>, <delete>, <renew>, <transfer>, and 
<update> commands. 


5. Formal Syntax 


The EPP Registry Maintenance Notification schema is presented here. 


The formal syntax is a complete schema representation of the object mapping suitable for 
automated validation of EPP XML instances. The <CODE BEGINS> and <CODE ENDS> tags are not 
part of the schema; they are used to note the beginning and end of the schema for URI 
registration purposes. 
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5.1. Registry Maintenance Notification EPP Mapping Schema 
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<CODE BEGINS> 
<?xml version="1.0" encoding="UTF-8"?> 

«schema targetNamespace="urn:ietf:params:xml:ns:epp: 
maintenance-1.0" 
xmins :eppcom="urn:ietf:params:xml:ns :eppcom-1.0" 
xmins :epp="urn:ietf:params:xml:ns:epp-1.0" 
xmlns:maint-"urn:ietf:params:xml:ns:epp:maintenance-1.0" 
xmlns="https://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified"> 

<l-- 

Import common element types 

--> 

«import namespace-"urn:ietf:params:xml:ns:eppcom-1.0"/» 

«import namespace-"urn:ietf:params:xml:ns:epp-1.0"/» 

«annotation» 
«documentation» 

Extensible Provisioning Protocol v1.0 
Registry Maintenance Notification Mapping Schema. 

</documentation> 

</annotation> 

<l-- 

Child elements found in EPP commands. 

--> 

<element name="info" type="maint:infoType"/> 

<l-- 

Child elements of the <info> command. 


--> 
<complexType name="infoType"> 
<sequence> 
<choice> 
<element name="list"/> 
<element name="id" type="maint:idType"/> 
</choice> 
</sequence> 
</complexType> 
<l-- 
Human-readable text may describe the maintenance 
--> 
<complexType name="idType"> 
<simpleContent> 


<extension base="token"> 
<attribute name="name" type="token"/> 
<attribute name-"lang" type="language" default="en"/> 
</extension> 
</simpleContent> 
</complexType> 
<l-- 
Info Response element 
C 
«element name="infData" type-"maint:infDataType"/» 
<l-- 
<info> response elements. 
--> 
<complexType name="infDataType"> 
<choice> 
«element name="list" type="maint:listDataType" /> 
«element name="item" type="maint:maintDataType" /> 


Sattler, et al. Standards Track Page 16 


RFC 9167 EPP Registry Maintenance December 2021 


</choice> 
</complexType> 
<l-- 
Attributes associated with the list info response 
--> 
<complexType name="listDataType"> 
<sequence> 
«element name="listItem" type="maint :maintItemType" 
minOccurs="@" maxOccurs="unbounded" /> 
</sequence> 
</complexType> 
<l-- 
Attributes associated with the list item info response 
--> 
<complexType name="maintItemType"> 
<sequence> 
<element name="id" type="maint:idType"/> 
<element name="start" type="dateTime"/> 
<element name="end" type="dateTime"/> 
<element name="crDate" type="dateTime"/> 
«element name="upDate" type-"dateTime" minOccurs="0"/> 
</sequence> 
</complexType> 
<l-- 
Attributes associated with the maintenance info response 
--> 
<complexType name="maintDataType"> 
<sequence> 
<element name="id" type="maint:idType"/> 
«element name-"type" type-"maint:typeType" minOccurs="0" 
maxOccurs="unbounded"/> 
<element name="pollType" type="maint:pollType" minOccurs="0"/> 
«element name-"systems" type="maint:systemsType" /> 
«element name-"environment" type="maint:envType"/> 
«element name="start" type="dateTime"/> 
<element name="end" type="dateTime"/> 
«element name="reason" type="maint :reasonEnum" /> 
«element name="detail" type="anyURI" minOccurs="@"/> 
«element name-"description" type-"maint:descriptionType" 
minOccurs="@" maxOccurs-"unbounded"/» 
«element name="tlds" type-"maint:tldsType" minOccurs-'0"/» 
«element name-" intervention" type-"maint:interventionType" 
minOccurs="0"/> 
«element name="crDate" type="dateTime"/> 
«element name="upDate" type-"dateTime" minOccurs="0"/> 
</sequence> 
</complexType> 
<l-- 
systems element 
--> 
<complexType name="systemsType"> 
<sequence> 
«element name="system" type-"maint:systemType" 
maxOccurs="unbounded"/> 
</sequence> 
</complexType> 


<l-- 


Enumerated list of poll types 
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--> 
<simpleType name="pollType"> 
<restriction base="token"> 
<enumeration value="create"/> 
<enumeration value="update"/> 
<enumeration value="delete"/> 
<enumeration value="courtesy"/> 
«enumeration value="end"/> 
</restriction> 
</simpleType> 
<l-- 
Enumerated list of impacts 
--> 
<simpleType name="impactEnum"> 
<restriction base="token"> 
«enumeration value-"none"/» 
«enumeration value="partial"/> 
«enumeration value="full"/> 
</restriction> 
</simpleType> 
<l-- 
description element 
--> 
<complexType name="descriptionType"> 
<simpleContent> 
<extension base="string"> 
<attribute name="lang" type="language" default="en"/> 
<attribute name="type" type="maint:descEnum" default="plain" 
Ife 
</extension> 
</simpleContent> 
</complexType> 
<l-- 
Enumerated list of description mime types 
--> 
<simpleType name="descEnum"> 
<restriction base="token"> 
<enumeration value="plain"/> 
<enumeration value="html"/> 
</restriction> 
</simpleType> 
<l-- 
type element 
--> 
<complexType name="typeType"> 
<simpleContent> 
<extension base="string"> 
<attribute name="lang" type="language" default="en"/> 
</extension> 
</simpleContent> 
</complexType> 
<l-- 
system element 
--> 
<complexType name="systemType"> 
<sequence> 
<element name="name" type="token"/> 
<element name="host" type="eppcom:labelType" minOccurs="@"/> 
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«element name-" impact" type="maint :impactEnum" /> 
</sequence> 
</complexType> 
<l-- 
Enumerated list of environments 
--> 
<simpleType name="envEnum"> 
<restriction base="token"> 
«enumeration value="production" /> 
«enumeration value="ote"/> 
<enumeration value="staging'/> 
«enumeration value="dev" /> 
«enumeration value="custom" /> 
</restriction> 
</simpleType> 
<l-- 
environment element 
--> 
<complexType name="envType"> 
<simpleContent> 
<extension base="token"> 
<attribute name="type" type="maint:envEnum" use="required"/> 
<attribute name="name" type="token" use="optional" /> 
</extension> 
</simpleContent> 
</complexType> 
<l-- 
Enumerated list of reasons 
--> 
<simpleType name="reasonEnum"> 
<restriction base="token"> 
«enumeration value="planned"/> 
<enumeration value="emergency"/> 
</restriction> 
</simpleType> 
<l-- 
tlds element 
--> 
<complexType name="tldsType"> 
<sequence> 
«element name="tld" type-"eppcom:labelType" 
maxOccurs="unbounded"/> 
</sequence> 
</complexType> 
<l-- 
intervention element 
--> 
<complexType name="interventionType'> 
<sequence> 
<element name="connection" type="boolean"/> 
«element name-" implementation" type="boolean"/> 
</sequence> 
</complexType> 
<l-- 
End of schema. 
--> 
</schema> 
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<CODE ENDS> 


6. IANA Considerations 


6.1. XML Namespace 


This document uses URNs to describe XML namespaces and XML schemas conforming to a 
registry mechanism defined in [RFC3688]. 


The following entry has been registered as an XML namespace: 


URI: urn:ietf:params:xml:ns:epp:maintenance-1.0 
Registrant Contact: IESG 
XML: None. Namespace URIs do not represent an XML specification. 


The following entry has been registered to the XML maintenance schema: 


URI: urn:ietf:params:xml:schema:epp:maintenance-1.0 
Registrant Contact: IESG 
XML: See the "Formal Syntax" section of this document. 


6.2. EPP Extension Registry 


The following entry has been added to the "Extensions for the Extensible Provisioning Protocol 
(EPP)" registry, described in [RFC7451]: 


Name of Extension: Registry Maintenance Notification for the Extensible Provisioning Protocol 
(EPP) 

Document status: Standards Track 

Reference: RFC 9167 

Registrant Name and Email Address: IESG <iesg@ietf.org> 

TLDs: Any 

IPR Disclosure: None 

Status: Active 

Notes: None 


7. Security Considerations 


The security considerations of [RFC5730] apply in this document. Additionally, a server MUST only 
provide maintenance information to clients that are authorized. Suppose a client queries a 
maintenance identifier that it is not authorized to access per Section 4.1.1.1, "Info Maintenance 
Item". In that case, the server SHOULD return an EPP error result code of 2201 ("Authorization 
error") or 2303 ("Object does not exist") [RFC5730]. The list of top-level domains or registry zones 
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returned in the "Info Maintenance Item" response SHOULD be filtered based on the top-level 
domains or registry zones for which the client is authorized. Authorization of poll messages is 
done at the time of poll message insertion and not at the time of poll message consumption. 
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